Сообщения протокола SIP
Структура сообщений
Согласно архитектуре «клиент-сервер» все сообщения делятся на запросы, передаваемые от клиента
к серверу, и на ответы сервера клиенту.
Например, чтобы инициировать установление соединения, вызывающий
пользователь должен сообщить серверу ряд параметров, в частности, адрес вызываемого пользователя,
параметры информационных каналов и др. Эти параметры передаются в специальном SIP-запросе. От вызываемого
пользователя к вызывающему передается ответ на запрос, также содержащий ряд параметров.
Все сообщения протокола SIP (запросы и ответы), представляют собой
последовательности текстовых строк, закодированных в соответствии с документом RFC 2279. Структура и синтаксис
сообщений SIP, как уже упоминалось ранее, идентичны используемым в протоколе HTTP. На рисунке 6 представлена
структура сообщений протокола SIP.
Стартовая строка |
Заголовки |
Пустая строка |
Тело сообщения |
Рис. 6 Структура сообщений протокола SIP
Стартовая строка представляет собой начальную строку любого SIP-сообщения.
Если сообщение является запросом, в этой строке указываются тип запроса, адресат и номер версии
протокола. Если сообщение является ответом на запрос, в стартовой строке указываются номер версии
протокола, тип ответа и его короткая расшифровка, предназначенная только для пользователя.
Заголовки сообщений содержат сведения об отправителе, адресате, пути следования и др., в общем,
переносят информацию, необходимую для обслуживания данного сообщения. О типе заголовка можно узнать
по его имени. Оно не зависит от регистра (т.е. буквы могут быть прописные и строчные), но обычно имя
пишут с большой буквы, за которой идут строчные.
Сообщения протокола SIP могут содержать так называемое тело сообщения. В запросах АСК, INVITE и
OPTIONS тело сообщения содержит описание сеансов связи, например, в формате протокола SDP. Запрос BYE
тела сообщения не содержит, а ситуация с запросом REGISTER подлежит дальнейшему изучению. С ответами
дело обстоит иначе: любые ответы могут содержать тело сообщения, но содержимое тела в них бывает разным.
В протоколе SIP определено четыре вида заголовков (Таблица 1):
• Общие заголовки, присутствующие в запросах и ответах;
• Заголовки содержания, переносят информацию о размере тела сообщения или об источнике запроса (начинаются со слова «Content»);
• Заголовки запросов, передающие дополнительную информацию о запросе;
• Заголовки ответов, передающие дополнительную информацию об ответе.
Заголовок содержит название, за которым, отделенное двоеточием, следует значение заголовка. В поле значения содержатся передаваемые данные. Следует отметить, что если сервер принимает сообщения, заголовки которых ему не известны, то эти заголовки игнорируются.
Ниже представлены наиболее часто используемые заголовки.
Заголовок Call-ID - уникальный идентификатор сеанса связи или всех регистрации отдельного клиента, он подобен метке соединения (call reference) в сигнализации DSS-1 . Значение идентификатору присваивает сторона, которая инициирует вызов. Заголовок Call-ID состоит из буквенно-числового значения и имени рабочей станции, которая присвоила значение этому идентификатору. Между ними должен стоять символ @, например, 2345call@rts.loniis.ru Возможна следующая ситуация: к одной мультимедийной конференции относятся несколько соединений, тогда все они будут иметь разные идентификаторы Call-ID.
Заголовок То - определяет адресата. Кроме SIP-адреса здесь может стоять параметр «tag» для идентификации конкретного терминала пользователя (например, домашнего, рабочего или сотового телефона) в том случае, когда все его терминалы зарегистрированы под одним адресом SIP URL. Запрос может множиться и достичь разных терминалов пользователя; чтобы их различать, необходимо иметь метку tag. Ее вставляет в заголовок терминальное оборудование вызванного пользователя при ответе на принятый запрос.
Если необходим визуальный вывод имени пользователя, например, на дисплей, то имя пользователя также размещается в поле То.
Заголовок From - идентифицирует отправителя запроса; по структуре аналогичен полю То.
Таблица 1 Виды заголовков сообщений SIP
Общие заголовки |
Заголовки содержания |
Заголовки запросов |
Заголовки ответов |
Call-ID (идентификатор сеанса связи) |
Content-Encoding (кодирование тела сообщения) |
Accept (принимается) |
Allow (разрешение) |
Contact (контактировать) |
Content-Length (размер тела сообщения) |
Accent-Encoding (метод кодирования поддерживается) |
Proxy-Authenticate (подтверждение подлинности прокси-сервера) |
CSeq (последовательность) |
Content-Type (тип содержимого) |
Accent-Language (язык поддерживается) |
Retro-After (повторить через некоторое время) |
Date (Дата) |
|
Authorization (авторизация) |
Server (сервер) |
Encryption (шифрование) |
|
|
Unsupported (не поддерживается) |
Expires (срабатывание таймера) |
|
Hide (скрыть) |
Warning (предупреждение) |
From (источник запроса) |
|
Max-Forwards (максимальное количество переадресаций) |
WWW-Authenticate (подтверждение подлинности WWW-сервера) |
Record-Route (запись маршрута) |
|
Organization (организация) |
|
Timestamp (метка времени) |
|
Priority (приоритет) |
|
То (Адресат) |
|
Proxy-Authorization (авторизация прокси-сервера) |
|
Via (через) |
|
Proxy-Require (требуется прокси-сервер) |
|
|
|
Route (маршрут) |
|
|
|
Require (требуется) |
|
|
|
Response-Key (ключ кодирования ответа) |
|
|
|
Subject (тема) |
|
|
|
User-Agent (агент пользователя) |
|
Заголовок CSeq - уникальный идентификатор запроса, относящегося к одному
соединению. Он служит для корреляции запроса с ответом на него. Заголовок состоит из двух частей: натурального
числа из диапазона от 1 до 232 и типа запроса. Сервер должен проверять значение CSeq в каждом принимаемом запросе
и считать запрос новым, если значение CSeq больше предыдущего. Пример заголовка: CSeq: 2 INVITE.
Заголовок Via служит для того, чтобы избежать ситуации, в которых запрос
пойдет по замкнутому пути, а также для тех случаев, когда необходимо, чтобы запросы и ответы обязательно проходили
по одному и тому же пути (например, в случае использования межсетевого экрана - firewall). Дело в том, что запрос
может проходить через несколько прокси-сервером, каждый из которых принимает, обрабатывает и переправляет запрос к
следующему прокси-серверу, и так до тех пор, пока запрос не достигнет адресата. Таким образом, в заголовке Via
указывается весь путь, пройденный запросом: каждый прокси-сервер добавляет поле со своим адресом. При необходимости
(например, чтобы обеспечить секретность) действительный адрес может скрываться.
Например, запрос на своем пути обрабатывался двумя прок си-серверами:
сначала сервером loniis.ru, потом sip.telecom.com. Тогда в запросе появятся следующие поля:
Via: SIP/2.0/UDP sip.telecom.com:5060;branch=721 e418c4.1 Via: SIP/2.0/UDP
loniis.ru: 5060,
где параметр «branch» означает, что на сервере sip.telecom.com запрос был размножен и направлен одновременно по
разным направлениям, и наш запрос был передан по направлению, которое идентифицируется следующим образом: 721е418c4.1.
Содержимое полей Via копируется из запросов в ответы на них, и каждый сервер,
через который проходит ответ, удаляет поле Via со своим именем.
В заголовок Record-route прокси-сервер вписывает свой адрес - SIP URL, - если
хочет, чтобы последующие запросы прошли через него.
Заголовок Content-Type определяет формат описания сеанса связи. Само описание
сеанса, например, в формате протокола SDP, включается в тело сообщения.
Заголовок Content-Length указывает размер тела сообщения.
|